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INTRODUCTION 


During  the  last  decade,  numerically  controlled  (N/C)  flame  cutting 
systems  have  established  themselves  firmly  as  an  integral  part  of  the 
shipbuilding  industry,  but  the  computer  software  systems  which  have  been 
developed  to  generate  the  N/C  instructions  prove  to  be  a  continually 
growing  and  expanding  component  of  the’  process.  A  number  of  such  systems 
are  commercially  available,  all  vigorously  developing  new  capabi.liti.es 
which  are  marketed  as  successive  versions  of  the  systems. 

This  paper  cites  directions  of  new  development  in  a.  number  of 
the-leading  systems  and  generalizes  to  identify  several  visible  trends 
in  the  development  of  shipbuilding  software,  systems.  These  trends  are 
explained  in  terms  of  the  technical  and  economic  mechanisms  driving 
them.  We  should  expect  these  trends  to  culminate  in  a  new  payoff  of 
benefits  distinct  from  the  advantages  which  we  currently  realize  from 
N/C  processes. 

The  pathway  from  the  present  situation  to  the  realization  of  this 
payoff  contains  pitfalls,  however.  This  paper  will  attempt  to  illuminate 
one  such  hazard  which  has  been  ‘underpublicized,  which  we  can  do  something 
about,  and  which  we  must  act  on,  now  or  the  opportunity  will  be  lost. 


TRENDS 

As  in  most  businesses  today,  electronic  data  processi.ng  (EDP)  is 
well  established  in  the  administrative  operation  of  shipyards;  in  this 
paper  we  are  not  primarily  concerned  with  that  usage  of  computing.  In 
technical  functions,  programs  have  long  been  used  for  weight  calcula¬ 
tions,  structural  analysis,  and  a  modest  number  of  other  isolated 
scientific  tasks,  but  this  usage  has  had  a  correspondingly  modest  impact 
on  the  ship  design  and  construction  process  in  our  shipyards.  The  first 
major  impact  of  the  computer  on  the  design/production  shipyard  operation 
has  been  to  support  N/C  flame  cutting. 

N/C  tapes  were  initially  produced  very  laboriously  using  rudimentary 
parts  programming  languages.  The  effort  of  loading  digital  data  to 
produce  N/C  tapes  has  subsequently  been  reduced  with  the  development 
of  more  sophisticated  parts  programming  languages,  with  the  usage  of 
“macros”  and  “norms,”  and  by  the  technique  of  storing  the  hull  molded 
surface  one  time  and  merely  referencing  it  as  necessary  for  position 
information  respecting  particular  parts.  Eventually  algorithms  were 
added  to  fair  the  hull  surface  and  to  assist  in  loading  data  respecting 
longitudinal  stiffening  into  the  data  file,  also  to  be  referenced  when 
defining  parts.  The  original  motivations  for  this  aggregate  parts 
programming  capability  were  the  reduced  cost  and  increased  dimensional 
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accuracy  of  automated  manufacture,  and  the  successive  development  of  the 
capability  has  been  driven  by  the  need  to  reduce  costs  of  the  N/C  input 
task.  The  ongoing  extension  of  this  trend  in  today’s  shipbuilding  N/C 
systems  is  toward  inclusion  of  capabilities  explicitly  for  the  design/ 
engineering  phase  of  the  shipbuilding  process.  The  continuing  and 
apparently  natural  growth  of  computer  impact  is  from  the  Production 

Department  back  up  through  the  process  into  Design  and  Engineering. 


|  Figure  1 
of  the  princip 
efforts  are  me 
there  is  an  aj 
cope  with  this 
significant  tre 

cites  some  of  the  newer  areas  being  emphasized  in  several 
al  shipbuilding  computer  systems.  These  development 
rre  fully  described  in  references  through  7.  Although 
>parent  diversity  of  development  emphasis,  it  will  help  us 
expanding  field  if  we  recognize  and  accept  that  the  most 
:nd  in  shipbuilding  computer  systems  is  their  continual 

incorporation  of  additional  functions. 

Figure  2 

represents  this  dominant  trend  as  the  phenomenon  of 

increasing  higher  integration  of  these  systems  in  five  distinct  dimensions. 

We  have  already  noted  the  extension  of  systems  "up  the 
process”  in  the  direction  of  design/engineering,  and 
more  will  be  discussed  on  this  later. 

•  We  can  see  also  the  inclusion  in  the  automated  process 
of  more  parts  of  the  ship  structure,  such  as  transverse 
structure  and  small  structural  parts  (chocks,  tripping 
brackets,  sole  plates,  etc.),  and  one  may  reasonably 
extrapolate  the  trend  to  eventually  encompass  foundations. 

•  Some  systems  are  beginning  to  integrate  across  design 
disciplines  to  facilitate  coordination  of  piping,  struc¬ 
ture,  and  arrangements. 

•  There  is  a  growing  awareness  of  the  need  to  integrate 
the  technical  data  with  data  files  for  management 
and  administrative  functions  (estimating,  scheduling, 
progress  reporting,  procurement,  etc.).  In  a  landmark 
state-of-the-art  survey  of  computer-aided  design  (CAD), 
Hatvany  et  al  state: 

The  satisfactory  solution  to  creating  an 
efficient  output  interface  for  CAD  in  each 
case  requires  basic  consideration  of  the 
integration  of  the  entire  design,  manufac¬ 
turing,  and  administrative  process.  With¬ 
out  this,  only  partial  ad  hoc  solutions  can 
be  found.  (Reference  8) 


WORLIMIDE  SHIPBUILDING  COMPUTER  SYSTEMS  ARE  EMPHASIZING  NEW  APPLICATIONS 


•  AUTOKON:  OUTFITTING,  structural  detailing,  structural  analysis  optimization,  piping 

ARRANGEMENT,' GENERAL-PURPOSE  DRAFTING  -  ... 

•  BRITISH  SHIP  RESEARCH  ASSOCIATION,  SHIP  STRUCTURAL  DESIGN  SYSTEM  (SSDS):.  integration  , 

OF  DESIGN  AND  PRODUCTION,  CENTRAL  DATA  BASE,  STANDARD  STRUCTURAL  DETAILS 

•  ITALCANTIERI,  SCAFO  SYSTEM  &  OTHERS:  highly 'integrated  system  of  structural  &  arrange¬ 

ments  DESIGN  PROGRAMS  WITH  MANUFACTURING  &  PROCUREMENT-ORIENTED  SOFTWARE 

•  HITACHI,  FNC  SMALL  SYSTEM:  incorporates  small  structural  parts  into  automated 

PRODUCTION  PROCESS 

•  KOCKUMS:  INCORPORATING  SMALL  STRUCTURAL  PARTS,  emphasizing  PUNNING  AND  administrative 

FUNCTIONS 

•  SPADES:  PRODUCTION  PUNNING  &  SCHEDULING,  STEEL  MATERIAL  CONTROL,  STRUCTURAL  DRAFTING, 

MORE  POWERFUL  STRUCTURAL  DATA  LOADING 

FIGURE  1 


THE  MOST  SIGNIFICANT  TREND  IN  SHIPBUILDING  COMPUTER  SYSTEMS  IS  THEIR 
CONTINUAL  INCORPORATION  OF  ADDITIONAL  FUNCTIONS, 

THIS  TREND  MAY  BE  CHARACTERIZED  AS  INCREASING  HIGHER  INTEGRATION  IN  5  DIMENSIONS: 

THROUGHT  the- shi p  DESI GN/  PRODUCTI  ON  PROCESS 

INCORPORATING  MORE  OF  SHIP  STRUCTURE 

ACROSS  'DESIGN  DISCIPLINES 

WITH  ADMINISTRATIVE  FUNCTIONS 

WITH  OTHER  ORGANIZATIONS  IN  INDUSTRY 

FIGURE  2 
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•  Finally,  the  high  cost  of  developing  and  main¬ 
taining  these  increasingly  complex  systems  is 
demanding  that  users  pool  their  resources  with 
other  industry  organizations,  thereby  requiring 
and  establishing  a  level  of  integration  across 
corporate  lines. 


In  the  growth  of  shipbuilding  computer  systems,  we  can  observe 


two  forms  of  accumulative  integration,  as  depicted  in  Figure  3. 
gential  integration,  wherein  one  original 


Tan- 


core  program  is  succes¬ 
sively  expanded  to  encompass  additional  adjacent  tasks,  is  perhaps  best 
representative  of  our  overall  trend.  Often,  however,  two  programs 
begun  independently  grow  together  as  one  or  both  incorporate  functions 
which  link  them.  We  can  refer  to  this  clustering  phenomenon  as  hier¬ 
archical  integration,  because  it  often  occurs  recursively  within  an 
organization’s  functions. 


TWO  FORMS  OF  INTEGRATION  GROWTH 


TANGENTIAL  INTEGRATION 


o  STAND-ALONE 
•Op  SYSTEMS 
ELEMENTS 


2nd  LEVEL 
INTEGRATION 


1st  LEVEL 
INTEGRATION 


OF INAL  (OR 

CURRENT)  LEVEL 
OF  INTEGRATION 


HIERARCHICAL  INTEGRATION 


FIGURE  3 
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As  an  example  of  hierarchical  integration,  in  the  Navy’s  Computer- 
Aided  Design  and  Construction  (CASDAC)  system  (reference  9)  we  have 
seen  manual  dsiign  tasks  replaced  or  facilitated  by  stand-alone  com¬ 
puter  programs  (e.g.,  the  UPLOT  programm  for  computer-assisted  drafting). 
Stand-alone  programs  have  often  been  consolidated  into  suites  of  com 
plementary  programs  (e.g.,  combining  UPLOT  with  an  interactive  graphics 
arrangement  program,  COGAP,  to  provide  improved  arrangements  drawings). 
Program  suites  have  been  superseded  by  larger  "subsystems”  “which  address 
entire  design  disciplines  (e.g.,  the  new  Arrangements  Subsystem  provides 
a  full  complement  of  ship  arrang  ernents  functions,  including  those  of 
COGAP/UPLOT).  These  subsystems  must  be  interfaced  to  comprise  a  total 
coordinated  computer-aided  contract  design  system  “(CASDAC  Level  III), 
and  this  system  will  eventually  be  required  to  interface  with  shipyard 
design  and  with  the  vendor  community. 

Whether  a  particular  step  toward  higher  integration  is  pre¬ 
dominantly  tangential  or  predominantly  hierarchical,  the  most  common 
motivation  is  the  situation  where  a  new  and  common  functional  boundary 
exists,  across  which  information  passes  and  which  is  inefficient  to 
support  manually.  Before  integration,  this  data  flow  requires  manual 
(or  perhaps  computer-assisted)  copying,  reformatting,  calculations 
and/or  re-digitizing  (e.g.,  card  punching)  which  incur  inordinate 
expense  and  which  could  be  alleviated  by  making  the  two  functions  or 
programs  or  systems  “talk  to  each  other.”  As  an  illustration,  consider 
how  interactive  graphics  parts  nesting  bypasses  the  plotting  and 
cutting  out  of  small-scale  parts  templates,  the  manual  nesting  of  the 
templates,  the  recapturing  of  digital  part  position  data  via  digitizer 
or  manual  card  punching,  and  the  verification  of  nested  formats  in 
batch  mode  plotting.  Henceanother  step  up  the  integration  ladder. 

There  are  several  other  visible  trends  in  shipbuilding  computer 
systems  which  are  accompanying  the  higher  integration.  There  has  been  a 
startling  popularity  in  the  last  two  years  of  interactive  graphics, 
whereas  the  traditional  mode  of  operation  has  been  batch  mode  with 
punched  card  input.  Interactive  graphics  technology  has  come  of  age, 
and  is  finding  effective  roles  in  parts  definition,  nesting,  and 
arrangements. 

Another  definite  trend  is  the  increasing  cost  of  the  more  complex, 
more  highly  integrated  systems.  One  shipyard  indicated  that  the 
operation,  maintenance,  and  modification  of  its  N/C  system  required 
the  continual  effort  of  between  three  and  six  programmers.  The  cost 
estimated  to  convert  to  a  second  computer  and  to  document  another  large, 
contemporary  shipbuilding  system  is  well  into  seven  figures.  Our 
computer  software  is  becoming  a  very  expensive  commodity  of  the 
trade . 
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Finally,  a  trend  of  vital  importance  to  this  discussion  is  that 
system  developers  are  recognizing  the  design  data  base  as  the  central 
element  of  the  design  system.  The  British  Ship  Research  Association 
(BSRA)  describes  their  Base  System  as  the  "kernel"  of  their  new  Ship 
Structural  Design  System  (SSDS).  A  particular  characteristic  of 
progressive  design  data  bases  is  their  use  of  topological  data  struc- 
ture.  This  technique  is  currently  being  used  in  defining  the  spatial 
retionships  among  surfaces,  lines  of  surface  intersection,  and  volumes 
bounded  by  the  Surfaces.  With  this  method  the  absolute  coordinates 
of  intersection  lines  are  not  explicitly  recorded;  instead,  the 
geometric  shapes  of  the  intersecting^  surfaces  are  recorded  and  are 
retrieyed  /and  operated  upon  to  compute  the  lines  of  intersection 
when  these  are  required.  |  Figure  4  illustrates  such  topological 
data  in  a  Navy  arrangements  program  (reference  10)  and  [Figure  ‘ 


illustrates  topologically  recorded  intersections  between  longitudinal 
surfaces  (decks,  bulkheads,  tank  tops,  etc.)  and  the  hull  in 
Italcantieri’ s  SCAFO  system. 
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SAMPLE  TOPOLOGICAL  DATA  STRUCTURE  IN 
THE  INTEGRATED  SHIP  DESIGN  SYSTEM 

FIGURE  4 
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LONGITUDINAL  SURFACES 
REPRESENTED  TOPOLOGICALLY  IN 
ITALC ANTIERI '  S  SCAFO  SYSTEM 


FIGURE  5 


In  his  paper  (reference  1)  for  the  1977  REAPS  Symposium, 

Jan  Mack  identifies  and  discusses  these  three  benefits  of  topological 
data  structure: 

•  bess  data  input 

•  Ease  of  updating  changes 

•  Flexibility  in  work  sequence 

It  should  be  noted  that  a  corollary  to  "ease  pf  updating  changes" 

is  the  fact  that  in  a  topological  data  structure  data  redundancy  is 
minimized  and  therefore  the  data  base  is  inherently  morp  consistent. 
Italcantieri  claims  that  SCAFO1 s  topological  data  structure  affords  a 


very  desirable  flexibility  in  work  sequence,  due  to  the  fact  that 
changes  to  the  molded  surface  locations  of  both  shell  and  internal 
surfaces  do  not  require  radical  recomputation  of  many  structural 
details. 

It  should  be  understood  that  the  benefits  of  a  topological  data 
structure  described  above  are  germane  while  the  data  are  in  a  state 
of  change.  Once  a  design  has  stabilized,  it  is  often  more  efficient 
to  freeze  the  design  and  record  the  data  in  absolute  form  for  direct 
use  thereafter.  An,  effective  data  management  system  should  allow 
this  transition  from  topological  to  absolute  data  representation  during 
each  design. 


THE  PAYOFF 


Why  Benefits  Are  Expected 

Before  contemplating  the  specific  anticipated  benefits  of  more 
highly  integrated  systems,  it  will  be  helpful  to  understand  the 
mechanisms  at  work  which  yield  these  benefits.  I  will  identify  and 
briefly  describe  three  such  mechanisms. 

MECHANISM  #1:  ONCE  DESIGN  INFORMATION  IS  "CAPTURED” 

AS  DIGITAL  DATA,  IT  CAN-DRIVE  MANY  APPLICATIONS. 

As  a  familiar  example,  consider  the  spin-off  benefits  which  became  avail 
able  at  very  little  additional  effort  once  N/C  systems  had  recorded 
shell  plates  and  hull  longitudinal.  Roll  templates  and  3-D  templates 
for  developed  plates  were  easily  produced.  Inverse  curve  data  for 
bending  frames  and  longitudinals  was  made  available,  and  tables  of  pin 
heights  for  shell  assemblies  were  generated.  These  capabilities  elimi¬ 
nate  much  manual  transcribing  of  data,  checking,  and  resolving  of  errors 

Similarly,  it  is  a  trivial  matter  to  compute  percentage  of  scrap  and 
times  required  to  punch  and  burn  each  plate,  given  information  required 
for  an  N/C  tape  itself. 

MECHANISM  #2:  SHIFTING  THE  "DIGITAL  FRONTIER"  FROM 
THE  PARTS  PROGRAMMING  STEP  TO  A  POINT  EARLIER  IN  THE 
DESIGN  PROCESS  GREATLY  REDUCES  THE  QUANTITY  OF  DATA 
TO  BE  LOADED. 


We  know  that  the  quantity  of  design  information  grows  exponentially 
during  the  design  process.,  probably  as  the  exponential  "S"  curve 
illustrated  in 


Figure  6 .  Presently,  detail  structural  design  is  per¬ 


formed  manually,  and  at  the  conclusion  of  detail  design  the  structural 


MECHANISM  #2:  SHIFTING  "DIGITAL  FRONTIER"  FROM  PARTS 
PROGRAMMING  TO  EARLIER  IN  DESIGN  PROCESS  GREATLY  REDUCES 
QUANTITY  OF  DATA  TO  BE  MANUALLY  LOADED. 
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FIGURE  6 
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geometry  is  transformed  into  digital  data  during  parts  programming,  a 
very  time-consuming  task.  As  the  increasing  usage  of  CAD  in  detail 
design  shifts  this  "digital  frontier"  up  earlier  in  the  design  process, 
less  input  will  have  to  be  manually  loaded  and  the  bulk  of  the  input 
data  required  later  in  the  process  will  be  generated  by  the  new  design 
programs. 

MECHANISM  #3:  INTEGRATED  SYSTEMS  CAPITALIZE  ON 
CONTINUITY  OF  FLOW  OF  CONSISTENT  DATA  THROUGHOUT 
THE  PROCESS. 

We  have  already  been  introduced  to  this  concept  as  the  most  frequent 
motivation  for  integration.  Since  the  manual  handling  of  digital  data 
is  generally  espensive,  error- prone,  and  unnecessary  it  is  useful  in 
system  design  to  be  conscious  of  continuity  of  data  flow  in  the  system, 
recognizing  that  flow  continuity  usually  requires  that  the  form  of  data 
be  consistent  as  well  as  the  information  content. 


Bearing  in  mind  these  three  mechanisms  and  recognizing  that  various 
computer-aided  design  software  exists  now  or  is  under  rapid  development 
in  the  early  design  stages  (PRELIKON,  Sener's  FORAN,  Navy’s  CASDAC 
Level  111),  detail  design  stands  out  as  representing  the  major  gap  in 
the  flow  of  digital  data  (see  Figure  7).  As  the  CAD  software  in  early 
design  matures  to  produce  a  complete,  reliable  contract  design  data 
base,  and  as  current  development  efforts  move  the  digital  frontier 
backward  from  parts  programming  across  detail  design  to  meet  that  data 
base,  we  may  expect  to  see  a  marked  improvement  in  the  effectiveness  of 
our  system  as  that  gap  is  bridged.  Such  integration  of  the  design  and 
manufacturing  functions  will  realize  much  greater  benefits  than  would 
the  independent  sub-optimizations  of  each. 


Benefits  in  Structural  Design 


Once  the  structural  geometry  definition  of  the  ship,  is  being 
stored  and  used  in  digital  form,  the  structural  engineer  will  have 
a  versatile  and  convenient  means  for  obtaining  graphic  representations 
of  the  current  structural  configuration.  He  may  request  plans  for 
whole  decks  or  bulkheads,  he  may  ask  for  sketches  of  arbitrary  sections 
through  existing  structure,  or  he  may  ask  for  particular  local  details. 

He  may  identify  which  views  he  would  like  shown  and  how  he  wants  them 
formatted  on  a  drawing.  He  may  designate  which  structural  surfaces  or 
elements  he  wants  shown,  the  level  of  detail  he  wishes  depicted  (scantling 
drawing,  structural  drawing,  structural  details),  and  he  may  selectively 
call  for  inclusion  or  suppression  of  notes,  piece  numbers,  weld  symbols, 
labels,  dimensions,  etc.  In  short,  the  engineer  no  longer  must  pick  the 
information  he  needs  off  standard  drawings  whose  format  and  content  were 
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decided  by  others;  he  may  now  very  quickly  compose  sketches  and  drawings 
to  suit  his  individual  and  immediate  needs. 

The  structural  graphic  representations  just  described  would  be 
available  via  several  mediums.  Interactive  graphics  terminals  would  serve 
as  the  primary  man/machine  interface.  The  engineer  would  compose 
displays  exercising  the  capabilities  and  options  described  above.  He 
would  get  electrostatic  copies  of  the  displays  virtually  instantaneously, 
and  he  would  use  these  copies  directly  for  reference  in  much  of  his  own 
design  work.  High  quality  drawings,  when  required,  would  be  produced 
from  the  graphics  display  via  drafting  machine. 

In  one  of  our  more  progressive  shipyards  which  uses  one  of  the 
popular  N/C  systems,  engineers  have  begun  to  request  drawings  of 
molded  contours  from  the  N/C  data  base.  These  drawings  they  then 
arrange  in  appropriate  locations  under  a  fresh,  sheet  of  mylar  and  the 
contours  are  manually  traced  as  the  outlines  of  their  new  bulkhead 
drawings.  Certainly  this  procedure  can  be  adjusted  to  more  conveniently 
serve  the  engineer’s  need,  but  the  significant  point  is  that  the  data 
base  and  its  graphic  output  capability  have  been  recognized  as  a 
precise  and  reliable  means  of  obtaining  molded  surface  information. 

It  certainly  beats  manual  interpolation  from  a  book  of  offsets,  or 
scaling  down  a  1/10  body  plan  to  an  appropriate  scale!  The  proposed 
capability  for  producing  displays  and  drawings  of  the  structural 
configuration  is  merely  the  extension  of  this  basic  capability  to  its 
full  potential. 

The  last  few  paragraphs  have  described  both  passive  and  interactive 
graphics  as  useful  output  tools.  Interactive  graphics  will  also  be 
used  to  provide  the  designer  with  a  convenient  and  powerful  tool  for 
de  fining -structural  geometry  to  the  data  base,  eliminating  most  of  the 
card  input/batch  mode  data  entry  we  know  today.  Programs  on  inter¬ 
active  cathode  ray  tube  (CRT)  scopes  will  display  existing  structure 
as  described  above,  then  will  assist  in  structural  design  by  quickly 
arranging  grids  of  stiffeners  at  designated  spacings,  running  seams  and 
stiffeners  parallel  to  existing  structure,  repeating  groupings  of  minor 
structure,  etc.  Immediate  visual  confirmation  will  reduce  input  errors 
common  in  batch  mode  operation.  Where  appropriate,  computer-produced 
sketches  of  existing  structure  can  be  manually  marked  up  to  show  modi¬ 
fication  and/or  new  structure,  and  these  modifications  can  be  input  via 
digitizer  device  working  from  the  marked  - up  sketch. 

Topological  data  methods  would  be  used  not  only  to  represent 
molded  surface  intersections,  but  also  to  record  stiffening  located 
on  a  surface  and  to  identify  the  extents  of  structural  numbers.  For 
instance,  toe  traces  of  bulkhead  stiffeners  might  be  defined  to  align 


with  a  deck  longitudinal  above  and  a  bottom  longitudinal  below.  If 
the  location  or  scantling  of  the  deck  longitudinal  were  to  change,  it 
would  require  no  modification  to  the  topology  of  the  bulkhead  stiffener. 
Since  detailed  piece  lengths  and  end  cut  details  would  not  be  stored 
explicitly,  they  would  require  no  updates.  The  structural  design  tasks 
would  realize  the  benefits  of  topological  data  structure  discussed 
earlier  in  this  paper. 

Structural  piece  lists  could  be,  generated  with  practically  no 
effort  and  in  virtually  zero  calendar  time.  Manual  "material  take-offs" 
from  drawings  would  disappear  and  the  piece  lists  would  be  consistent 
with  both  drawings  and  data  base.  Furthermore,  variations  of  piece 
lists  could  be  tailored  to  particular  uses  at  very  little  cost,  to 
provide  various  formats,  meaningful  subsets  of  lists,  or  different 
ordering  of  list  items. 

Availability-of  digital  structural  data  would  feed  a  variety  of 
analysis  programs  from  simple  section,  modulus  calculations,  to  indetermi¬ 
nate  frame  analyses,  to  providing  data  for  a  closer  interface  with 
finite  element  methods.  Structural  weights  and  centers  of  gravity  could 
be  computed  automatically,  precisely,  and-as  often  as  necessary. 

The  existence  of  a  structural  data  base  would  assist  in  foundation 
design  by  providing  s-ketches  of  local  primary  structure.  The  digital 
description  of  equipment  location,  coupled  with  graphics  templates  of 
mounts,  base  plates,  bolt  hole  configuration,  etc.,  would  enable 
superposition  of  mounting  details  on  the  local  structure  sketches.  The 
convenience  of  this  capability  alone  would  considerably  facilitate  the 
manual  foundation  design  task.  A  more  ambitious  interactive  foundation 
design  capability  would,  compute  support  forces  due  to  various  loads, 
would  allow  the  designer  to  interactively  describe  the  foundation  struc¬ 
ture,  would  compute  forces  and  stresses  in  the  foundation  structure,  and 
would  allow  the  designer  to  indicate  recommended  modifications  to  the 
local  principal  structure,  if  ne,ceyisary. 

Finally,  benefits  will  be  realized  from  linking  the  shipyards' 
detail  design  CAD  systems  with  contract'  design  data  bases  produced  by 
design  agents  or  by  the  .Navy  using  CAD  in  the  early  design  stages.  This 
availbility  of  scantling  plans  in  digital  form  will  further  reduce  the 
initial  data. loading  effort  required  in  the  yards,  will  make  digital 
structural  data  available  to  all  design  disciplines  very  early  in  detail 
design,  and  will  greatly  r.eduoe  the  number  of  consistency- type  errors 
in  the  contract  design  package. 
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Benefits  of  Integrated  Structural  Design  to  Other  Design  Disciplines 


The  capability  to  obtain  graphical  displays,  'sketches  and  draw¬ 
ings  of  structural  configurations  would  be  available  to  designers  in 
all  disciplines.  These  designers  would  call  for  structural  background 
graphics  in  whatever  useful  views  they  require,  upon  which  they  would 
variously  carry  out  their  tasks  of  equipment  arrangement,  piping  and 
wireway  routing,  locating  vent  trunks  and  ducts,  etc. 

The  integrated  data  base  would  contain  equipment  locations  and 
details  of  piping  connections  on  equipment,  thereby  providing  precise 
end  position  and  details  for  piping  design. 

A  consistent  record  of  structural  penetrations  would  be  maintained 
by  the  data  base,  correlating  each  penetration  with  the  pipe,  cable  or 
vent  duct  involved,  establishing  the  precise  location  and  representing 
the  details  of  the  penetration. 

The  greatest  benefit  to  be  realized  by  integrating  structural  design 
with  other  disciplines  will  be  regarding  the  control  of  physical  interfer¬ 
ences.  Composite  drawings  and  displays  would  acquire  data  from  all  discip¬ 
lines  to  combine  components  from  all  relevant  systems  into  one  picture.  As 
with  the  structural  graphics  capability,  any  views  and  various  levels  of 
detail  may  be  prescribed.  Several  colors  may  be  used  to  distinguish  among 
systems.  The  composite  capability  would  be  cheap,  easy,  and  would  provide 
data  highly  consistent  with  the  various  system  designs.  Ancillary  capabil¬ 
ity  would  include  interactive  resolution  of  interferences  by  allowing  on- 
the-spot  recommendations  for  modifications  to  remove  conflicts,  and 
analysis  modules  which  would  automatically  detect  interferences. 

New  Benefits  to  Production 


When  the  design/engineering  functions  begin  using  CAD,  new  benefits 
will  accrue  in  the  production  process  itself  and  there  will  be  a  marked 
improvement  in  economy  of  transition  from  design  to  production.  The 
parts  programming  effort  will  be  greatly  reduced  since  a  comprehensive 
digital  description  of  the  structural  geometry  will  already  exist. 

In  most  shipyards  using  N/C  methods  the  production  is  responsible 
for  interpreting  structural  drawings,  for  loading  the  structural  geometry 
onto  the  data  base,  and  for  updating  the  N/C  data  base  in  accordance  with 
successive  waves  of  drawing  revisions.  Much  effort  is  currently  expended 
in  identifying  these  design  mods  and  in  the  requisite  data  update.  The 
production  department  in  the  future  will  be  relieved  of  this  responsibility, 
since  an  up-to-date,  approved  data  base  will  be  availble  to  them  as  a 
natural  product  of  the  integrated  design  process. 
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Having  captured  basic  structural  design  in  digital  forms,  these 
data  become  a  "valuable  resource  in  production  planning.  The  struc¬ 
tural  pieces  can  be  easily  organized  to  form  the  assembly  tree  struc¬ 
ture,  thereby  establishing  the  assembly  units  and  assembly  sequences. 
Assembly  units  would  be  complete  with  all  small  parts  accounted  for,  and 
assembly  weights  would  be  computed  automatically.  Most  N/C  systems  now 
provide  N/C  statistics,  (burn  path  length  and  time,  punching  time,  per¬ 
centage  scrap,  etc.)  as  spin-off  information  for  use  in  production 
planning.  Similarly,  a  structural  design  data  base  would  classify  weld 
joints  as  to  standard  types  and  would  quantify  amounts  of  each  joint  type 
required  during  each  assembly  step. 

Structural  design  data  will  also  be  massaged  and  outputted 
variously  as  specialized  parts  lists,  special-purpose  fabrication 
sketches,  and  isometric  assembly  sketches.  Whereas  these  fabrication 
tailored  shop  instructions  are  expensive  to  produce  manually,  the  com¬ 
puter  can  generate  them  very  cheaply  once  the  basic  data  are  available. 


Programs  can  assist  in  assembly  lifting  calculations  by  computing 
weight,  center  of  gravity  and  forces,  by  showing  the  engineer  the  lifting 
sequence  in  interactive  graphic  animation,  and  by  preparing  sketches  of  the 
lifts  in  various  possitions. 

Benefits  Due  to  Coordination  of  Computer  Methods  Across  the  Industry 


We  have  already  discussed  the  escalating  costs  of  developing  and 
maintaining  shipbuuilding  computer  software  and  have  noted  that  this  trend 
is  driving  us  toward-cooperative  effort  in  such  software.  More  and  more, 
users'  clubs  of  various  N/C  systems  are  working  together  to  implement 
standard  "norms,"  specialized  input  procedures,  etc.  Whereas  in  the  early 
years  of  N/C  systems  it  was  quite  common  for  individual  shipyards  to 
customize  versions  of  the  software  for  their  own  use,  we  can  see  in  the 
SPADES  and  AUTOKON  Users'  Groups  a  higher  level  of  cooperative  effort.  In 
short,  a  higher  level  of  standardization  is  being  tolerated  to  attain 
lower  costs,  but  this  standardization  gives  occasion  for  other  benefits 
also . 


Perhaps  because  of  the  tight  control  on  SPADES  software  andthe 
consequent  standardized  usage  among  the  SPADES  community,  SPADES  ship¬ 
yards  have  been  able  to  subcontract  among  each  other  portions  of 
designs,  thus  easing  the  scheduling  bind  and  leveling  their  manpower 
curves.  While  this  type  of  flexibility  has  always  existed  in  manual 
design,  it  must  not  be  taken  for  granted  with  CAD  processes  because  yards 
or  design  offices  must  use  compatible  systems  in  order  for  such  subcon¬ 
tracting  to  be  effective.  Standardization  of  computer  methods  across  the 
industry  will  allow  management  to  retain  the  subcontracting  option. 
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More  than  any  other  ship  buyer,  the  Navy  suffers  from  lead-yard/ 
follow-yard  shipbuilding  problems.  The  independent  use  of  incompatible 
design  software  by  different  systems  compounds  the  problem;  cases  have 
occurred  where  both  lead  and  follow  yards  utilized  CAD  systems,  but 
where  the  lead  yard  was  required  to  repeat  the  design  manually  because  the 
data  from  its  CAD  systems  were  unintelligible  to  the  follow  yard's  system. 
Translated  into  a  national  emergency  situation,  this  peacetime  cost 
problem  becomes  a  severe  constraint  on  the  nation' s  ability  to  rapidly 
produce  naval  and  merchant  fleets.  As  with  subcontracting,  a  CAD  system 
more  integrated  on  the  industry  level  will  reduce  the  peacetime  acquisition 
costs  and  the  wartime  defense  constriction. 

Finally,  Industry-CAD  integration  would  produce  classes  of  ships  — 
Navy  and  commercial  —  which  are  more  nearly  identical  than  most  classes 
to  date.  This  conformity  has  a  significant  impact  on  reducing  life  cycle 
costs  attendant  to  logistics,  spare  parts,  training,  repair,  and  conversion. 

NECESSARY  STEP  TO  CAD  PAYOFF 

Development  of  mature,  effective  shipbuilding  CAD  systems  to  produce 
the  aforementioned  benefits  is  no  straightforward,  task.  Figure  8  records 
a  number  of  the  major  problems  we  are  encountering  as  we  move  toward  more 
highly  integrated  systems.  These  problems  are  discussed  in  reference  11. 

It  is  not  the  purpose  of  this  paper  to  address  all  these  issues  or  their 
solutions.  We  will  look  closely  at  the  last  problem  noted  for  these 
reasons:  (1)  it  has  not  generally  been  given  recognition  appropriate  to 

its  significance;  (2)  it  must  be  addressed  now  or  it  will  be  too  late;  and 
(3)  there  is  something  we  can  do  about  it, 

The  problem  to  be  considered  is  that  throughout  the  shipbuilding 
industry  we  are  developing  shipbuilding  software  to  address  particular 
immediate  tasks.  This  distributed  development  effort  is  largely  un¬ 
coordinated  and  we  may  be  sure  that  those  "successful"  programs  and 
systems  which  emerge  will  soon  need  to  integrate  with  other  programs/ 
systems,  and  that  because  of  our  lack  of  foresight,  such  integration 
will  be  difficult  at  best. 

The  Navy' s  CAD  development  over  the  last  decade  indicates  that  the 
most  serious  barrier  stems  from  differences  in  the  ways  that  individual 
programs/systems  represent  their  data.  Programs/systems  considered  for 
integration  generally  contain  overlapping  sets  of  data.  Each  program  has 
been  designed  to  handle  data  to  suit  its  own  needs  and  has  built  into  it 
determinations  respecting  the  logical  definition  of  data  entities,  the 
structure  of  the  data,  the  data  formats,  and  the  various  software  to 
perform  data  mangement  functions.  These  types  of  determinations  represent 
substantial  software  commitments  and  alteration  of  the  software  to  revise 
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PROBLEMS  TO  BE  ENCOUNTERED  WITH  MORE  HIGHLY  INTEGRATED  SYSTEMS 

RAPIDLY  DEVELOPING  TECHNOLOGY 
GRAPHICS 

DATA  BASE  MANAGEMENT  SYSTEMS 

Z  REVOLUTIONARY  VS.  EVOLUTIONARY  INTEGRATION  STRATEGY 

Z  IMPACT  ON  CURRENT  PRACTICE 

Z  HIGH  COST  OF  COMPUTER  SOFTWARE 

Z  SELECTION  FROM  AVAILABLE  COMPETITIVE  SYSTEMS 

Z  CONCURRENT  UNCOORDINATED  DEVELOPMENT  OF  SOFTWARE. 
WHICH  WE  WILL  SOON  TRY  TO  INTEGRATE 

FIGURE  8 
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these  items  is  generally  an  expensive  proposition.  As  we  have  seen,  the 
trend  is  that  when  independent  programs  become  productive,  users  recognize 
the  inefficiencies  of  their  manual  interfaces  and  propose  they  be  inte¬ 
grated.  It  is  at  this  point  that  the  data  differences  among  the  programs 
prohibit  integration.  If  we  are  to  turn  the  corner  on  the  high  cost 
of  progressive  integration,  we  must  better  coordinate  the  data  aspects 

of  our  respective  software  developments . 

Attacking  the  Data  Consistency  Problem 

Let's  consider  what  we  can  and  cannot  do  to  alleviate  the  data  con¬ 
sistency  problem  in  progressive  integration. 

First,  we  must  be  willing  to  project  our  vision  beyond  the  immediate 
development  tasks  —  those  which  have  visible  cost  justification  —  to 
future  needs  calling  for  more  complete  integration.  In  this  projection  we 
must  concentrate  on  the  probable  future  data  interfaces  among  system 
modules,  identifying  groups  of  design  data  which  will  be  needed  by  two  or 
more  modules. 


It  would  be  very  good  if  we  were  to  be  able  to  establish  and  enforce 
data  consistency  at  the  highest  level,  by  agreeing  to  standard  data 
management  software  and  standard  physical  file  structure.  Although  these 
measures  can  and  should  be  used  where  possible  at  lower  levels  of  integra¬ 
tion  (e.g.,  where  programs  are  merged  into  subsystems  within  a  company), 
it  would  be  optimistic  to  think  they  could  be  applied  now  to  industry-level 
system  integration.  Difficulties  stem  from  the  diverse  requirements  of 
applications,  from  the  limited  generality  of  today's  data  management 
technology  in  efficiently  serving  diverse  requirements,  and  from  the 
difficulty  of  accurately  predicting  long-range  data  management  needs  or 
state-of-the-art  capabilities. 


Accepting  the  impracticality  of  invoking  those  high  level  standards, 
let  us  proceed  with  the  next  best  thing:  to  establish  consistent  logical 
definition  of  design  data  to  serve  immediate  and  long-term  applications. 
Figure  9  summarizes  those  characteristics  of  data  comprising  its  logical 


definition,  as  opposed  to  the  physical  definition  of  data.  The  segregation 
of  logical  and  physical  data  definition  is  widely  recognized  as  a  critical 
factor  in  effective  future  systems.  Interpreted  to  our  situation,  this 
segregation  tells  us  that  we  users  must  get  our  logical  definitions 
straight  and  that  future  data  management  systems  must  be  responsible  to 
provide  efficient  physical  data  structure  without  our  applications  programs 
being  concerned  with  record  length,  blocking  factors,  string  versus  tree 
structures,  etc. 


The  time  for  industry  action  in  coordinating  logical  data  definitions 
is  now!  Figure  10  lists  seven  different  development,  projects  in  the  REAPS/ 
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LOGICAL  DATA 
DEFINITION 


PHYSICAL 
DATA  DEFINITION 


REFLECTS  THE  WAY  THE  APPLICATION 
PROGRAMMER  OR  USER  THINKS  OF  THE 
DATA. 

REPRESENT  REAL  WORLD  ITEMS.  OR 
APPLICATION  PROGRAM  MODEL  OF  THE 
REAL  WorLd  in  terms  (IF  ENTITES, 
ATTRIBUTES,  AND  LOGICAL  RELATION¬ 
SHIPS  AMONG  ENTITES. 


GOAL:  TO  PROVIDE  APPLICATION  Pro¬ 
grammers  a  NaTuRal  VIEW  of  Their 
DATA,  MAKING  PROGRAMS  EASIER  TO 
DEVELOP  AND  MAINTAIN. 

SEGREGATION  OF  LOGICAL  AND  PHYSICAL  DATA  DEFINITIONS  INSULATES 
Application  PROGRAMS  FroM  CHANGES  IN-DATA  STORAGE  DEVices  AND 
FROM  CHANGES  IN  PHYSICAL  DATA  MANAGEMENT  METHODS. 

FIGURE  9 


REFLECTS  THE  CONSIDERATIONS  OF  THE 
COMPUTER  SYSTEMS  PROGRAMMER. 


CONSIDERS  WHERE  ON  STORAGE  DEVICES  A 
SET  OF  INFORMATION  IS  LOCATED,  CONTENDS 
WITH  RECORD  LENGTHS,  BLOCKING  FACTORS, 

TYPES  OF  STORAGE  DEVICES,  TYPES  OF  PHYSICAL 

RELATIONSHIPS  (STRING,  LIST,  Array  ORGANI¬ 
ZATION)  . 

GOAL:  TO  ATTAIN  EFFICIENT  OPERATION  ON 
WHATEVER  DEVICES  ARE  USED. 


THESE  CURRENT  DEVELOPMENTS  HEAVILY  INVOLVE  SHIP  STRUCTURAL  DATA: 

REAPS  PARTS  DEFINITION  PROJECT 
REAPS  COST  ESTIMATING  PROJECT 
NAVY'S  CASDAC  LEVEL  III  HULL  SUBSYSTEM 
NAVY'S  CASDAC  LEVEL  IV  HULL  SYSTEM  (HULDAC) 

CONSOLIDATION  OF  AUTOKON76  WITH  THE  U.  S.  STANDARD  AUTOKON  71  AND  WITH  THE 
NEWPORT  NEWS,  VERSION  OF  AUTOKON 

CONSOLIDATED  AUTOKON/SPADES  FEASIBILITY  STUDY 

REAPS  PROPOSED  STRUCTURAL  DATA  BASE  DEFINITION  PROJECT 

THE  FUTURE  IS  NOW! 

FAILURE  TO  COORDINATE  LOGICAL  DATA  DEFINITIONS  OF  THE  ABOVE  DEVELOP¬ 
MENTS  WILL  GUARANTEE  MAJOR  OBSTACLES  TO  NECESSARY  FUTURE  DATA  INTER¬ 
FACES  IN  THE  U.  S.  SHIPBUILDING  INDUSTRY. 

FIGURE  10 
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Navy  community  alone,  in  which  digital  structural  design  data  play  a 
major  role.  Failure  to  coordinate  the  loqigal  definition  of  structural 
data  in  these  projects  will  guarantee  the  existence  of  major  obstacles  to 

necessary  future  interfaces  in  the  U.  S.  shipbuilding  industry. 


Several  pioneering  efforts  have  been  underway  this  last  year  to 
contend  with  logical  structural  data  definition.  In  our  work  with  the 
Hull  Detail  Design  and  Construction  (HULDAC)  System,  covering  the  hull 
discipline  for  CASDAC  Level  IV/V,  we  have  been  investigating  methods  of 


Figure  11 


is  an 


recording  logical  data  definition  for  ship  structure, 
example  of  part  of  a  typical  logical  definition.  We  are  coordinating 
our  work  on  the  hull  data  base  evolving  from  that  of  the  Naval  Ship 
Engineering  Center's  CASDAC  Level  III  Hull  Subsystem,  and  we  have  been 
following  closely  the  ongoing  REAPS  projects  and  have  been  including  in 
the  HULDAC  study  structural  data  requirements  indicated  by  those  projects. 


In  particular,  the  HULDAC  work  has  been  closely  keyed  to  the  Structural 
Data  Base  Definition  effort  initiated  by  Dick  Moore  of  Newport  News  Ship¬ 
building  Company  and  Doug  Martin  of  IITRI  and  proposed  to  be  adopted  as 
a  REAPS  research  and  development  project.  At  the  February  1978  REAPS 
Technical  Representatives  Meeting,  IITRI  presented  a  Project  Proposal 
Abstract  and  a  Working  Paper  describing  this  proposed  project  and  request¬ 
ing  technical  inputs  from  the  REAPS  member  yards.  Initial  response  to  this 
effort  was  not  enthusiastic,  apparently  because  the  relevance  of  this 
project  to  the  future  anticipated  benefits  of  computer  usage  in  shipbuilding 
was  not  clearly  set  forth.  It  is  the  purpose  of  this  paper  to  illuminate 
and  publicize  the  rationale  for  this  project. 


Recommended  Action  to  Coordinate  Ship  Data  Definition 


Figure  12 


enumerates  several  actions  which  should  be  taken  to  better 
coordinate  the  logical  definition  of  ship  data.  These  actions  should 
concentrate  first  on  structural  data  due  to  the  intense  development 
activity  in  this  discipline,  but  should  eventually  be  extended  to  include 
piping  and  other  design  disciplines. 


A  key  component  of  this  effort  should  be  the  execution  of  Structural 
Data  Definition  as  a  REAPS  research  and  development  project,  with  active 
support  in  defining  data  needs  from  knowledgeable  structural  engineers 
within  each  yard.  Close  liaison  must  be  maintained  between  this  project 
and  the  structural  data  being  defined  by  the  Navy  to  serve  HULDAC  and 
CASDAC  Level  ITT. 


Once  an  acceptable  Structural  Data  Definition  has  been  created,  a 
challenging  organizational/control  problem  will  be  to  establish  a  continuing 
mechanism  whereby  developers  and  users  of  shipbuilding  systems  will  be 
influenced  to  observe  the  standards. 
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LOGICAL  DATA  STRUCTURE 


PLATE 

PARENT-SURFACE 

MATERIAL-CODE 

THICKNESS 

EDGES  (  R  G  ) 

CONTOUR-NAME 
EXCESS-STOCK 
BUTT-JOINT-DETAILS  (RG) 

ADJOINING-PLATE 

STD-JOINT-TYPE 

MOLDED-EDGE-CONTOUR 

AUGMENTED-EDGE-CONTOUR 


LOGICAL  DATA  I)  DEFINITIONS 

PARENT-SURFACE:  IDENTIFIES  THE  DECK,  BULKHEAD,  SHELL  SURFACE,  ETC.,  WHIHIcH 

CONTAINS  THE  PLATE 


EDGES  (RG):  REPEATING  GROUP  OF  PLATE  EDGES,  EACH  EDGE  BEING  DEFINED  BY  A  BUTT, 

SEAM,  OR  INTERSECTION  CONTOUR  WITH  ANOTHER  STRUCTURAL  SURFACE  (E.G., 
MAIN  DECK  AT  EDGE). 


FIGURE  11 
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RECOMMENDED  COORDI NATI ON  IN  SHIP  DATA  DEFINITION 

CARRY  OUT  STRUCTURAL  DATA-DEFINITION  PROJECT  AS  FORMAL  REAPS  PROJECT. 

-  YARD  PARTICIPATION  TO  REVIEW  DEFINITIONS  AND  USAGE. 

-  COVER  DATA  IN  USE  AND  DATA  FOR  SOFTWARE  BEING  DEVELOPED, 

■  CLOSE  COORDINATION  Wl  TH  NAVY  DATA  DEFINITION, 

ESTABLISH  MECHANISM  FOR  CONTINUING  DATA  COORDINATION. 

-  CASD  DEVELOPERS  MUST  ADHERE  TO  STANDARD  DATA  DEFINITIONS. 

-  CASD  DEVELOPERS  MUST  SUBMIT  NEW  DATA  FOR  INCLUSION. 

EXPAND  DATA  DEFINITION  TO  INCLUDE  PIPING,  HVAC,  ETC. 


FIGURE  12 
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SUMMARY 


It  has  been  shown  that  two  of  the  most  dominant  trends  in  the  con¬ 
tinuing  evolution  of  shipbuilding  software  systems  are  the  increasing 
cost  of  developing  and  maintaining  this  software  and  the  recursive  cycles 
of  higher  integration  being  sought,  especially  now  in  the  detail  design/ 
engineering  functions.  We  must  recognize  these  trends  and  lay  strategy 
to  accommodate  them  through  more  cooperative  effort  and  by  extending  our 
vision  in  system  planning  beyond  the  immediate  development  tasks  to 
encompass  the  imminent  higher  levels  of  integration  beyond. 

The  effects  of-the  trend  toward  higher  integration  are  expected  to 
produce  large  benefits  to  the  design/engineering  functions  of  all 
disciplines,  to  produce  additional  benefits  to  the  production  function,  and 
to  upgrade  the  effectiveness  of  the  U.  S.  shipbuilding  industry  as  a  whole. 

One  very  important  necessary  step  toward  long-term  ' integration  is  to 
gain  control  of  the  diverse  logical  data  definitions, bei : ng  built  into 
concurrently  developed  programs  and  systems.  A  number  of  current  develop¬ 
ments  involve  overlapping  structural  design  data  and  the  involved  parties  — 
REAPS  and  the  Navy  in  particular  should  actively  promote  coordination 
of  this  common  data. 

The  Structural  Data  Definition  project  should  be  recognized  as  a 
vital  undertaking,  to  be  pursued  with  vigor  and  with  high  level  support 
from  shipyard  management. 
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